Remarks 



This case has been carefully considered in light of the Final Office Action dated 
November 3, 2005 wherein: claim 6 was rejected under 35 USC 112, second paragraph; claims 
1-3, 5-6 and 1 1-13 were rejected under 35 USC 102(b) on Kanfi (US Pat. No. 5,559,991); claim 
6 was rejected under 35 USC 102(e) on Sarkar (US 2004/0158730 Al); and claims 7-10 were 
rejected under 35 USC 102(b) on Uemura et al. (US Pat. No. 5,720,026). Reconsideration is 
respectfully requested. 

Claims 1, 5-7 and 1 1- 13 have been amended. Claims 1-3 and 5-13 remain pending in 
this case. 

Claim 6 has been amended to provide proper antecedent basis. Claim 6, particularly as 
amended, is believed to conform to the requirements of 35 USC 1 12. 

Claim 1 has been amended to correct a typographical error. In addition, the preamble to 
claim 1 has been amended to recite a "method for tracking incremental changes to a file, 
especially for a large and/or sparse file, for efficient backup thereof. This amendment to the 
preamble clarifies that the applicants' backup process advantageously tracks incremental changes 
for efficiently backing up large and/or sparse files. Moreover, this amendment helps to make 
clear distinctions between applicants' claimed invention and Kanfi. The preambles to claims 11- 
13 have been similarly amended. Likewise, in similar manner, the preamble to claim 6 has been 
amended to recite a "method for retrieving incremental changes to data." 

The changes to the preambles of the claims, as described hereinabove, have been made to 
clearly set forth the patentable subject matter and to clarify the distinctions between the 
applicants' claimed invention and the cited references. No new matter has been added in 
amending the preambles. Support for the amendments to the preambles is found throughout the 
specification, including, for example, in paragraphs [0029a], formerly paragraph [0012], and 
[0056]. 

Claim 1 has been amended further to recite "processing a write request relevant to at least 
one block of said file by storing changes in information for said file and by providing an 
indication that information stored in said at least one block of said file new data , said write 
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request providing the capability for application programs to determine changes to said file by 
reading only blocks of said file that contain new data." Claims 6, 7 and 11-13 have been 
similarly amended. Support for this amendment is found in the specification, for example, on 
page 3, paragraph [0008], lines 1-2; and in previously added paragraph [0029a], formerly 
original paragraph [0012]. No new matter has been added. 

The applicants respectfully traverse the rejection of claims 1-3, 5-6, and 11-13 under 35 
USC 102(b) on Kanfi for the following reasons. 

Kanfi describes dividing a file into blocks, then computing a signature for each block. In 
Kanfi, the backup utility must determine the changed blocks by reading the entire file and 
recomputing the data signature for each block. Then, only the blocks with a new signature are 
included in the incremental backup. 

Significantly, the applicants differ from Kanfi by not only providing a method for 
tracking incremental changes to a large and/or sparse file, but by processing a write request that 
provides "the capability for application programs to determine changes to said file by reading 
only blocks of said file that contain new data '\ as recited in amended claims 1, 7 and 11-13. 
Claim 6 has been similarly amended to recite: "such that application programs are provided 
with the capability of determining changes to said file system by reading only blocks that have 
been changed " 

Therefore, Kanfi' s method of computing heuristic signatures for incremental computer 
file backups, which requires reading the entire file and recomputing the data signature for each 
block, is totally different from the applicants's method, which advantageously provides 
application programs with the capability to determine changes to a file by reading only blocks 
that have changes, as recited in the applicants' amended claims. Claims 1-3, 5-6 and 11-13 are 
thus believed to be patentably distinct from Kanfi under 35 USC 102. 

The applicants respectfully traverse the rejection of claim 6 under 35 USC 102(e) on 
Sarkar for the following reasons. 

At the outset, the applicants respectfully submit that the example of block-level 
differencing given by the Examiner with respect to Sarkar on the top of page 8 of the Office 
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Action is not described anywhere in the Sarkar patent. Indeed, Sarkar does not teach or suggest 
any way of determining only the blocks that have changed, but rather Sarkar' s anti-virus scan 
determines whether a current PiTC of the entire file is different from an earlier PiTC of the 
entire file. Sarkar's anti-virus scan is thus in start contrast to the applicants 5 block-level 
incremental backups, as recited in amended claim 6, i.e: 

A method for retrieving incremental changes to backed up 
block level data, especially from large and/or sparse files, each file 
comprising a plurality of blocks, said method comprising the steps 
of: 

providing two time stamps to a file system in a read 
request; and 

returning information with respect to changes in said blocks 
made between times indicated by said two time stamps, such that 
application programs are provided with the capability of 
determining changes to said file system by reading only blocks 
that have been changed, [emphasis added] 

With respect to Sarkar, the Office Action further cites step 220 of Figure 2 ("iterate over 
new & changed files"). As stated in paragraph [0073] of Sarkar: 

In step 220, the AV software that will perform the batch mode scan 
of files in physical file system 170 invokes an API call to diret the 
file system to return all deltas, i.e., differences, between 
PiTC cumnt _scan and PiTC previous scan . Typically, this call is an iterator, 
which allows a caller to iterate through the files of interest, 
[emphasis added] 

Contrary to the implication in the Office Action, the "iterator" of Sarkar does not return block- 
level differences. Nowhere in the Sarkar patent are block-level differences ever even mentioned. 
On the other hand, Sarkar' s patent clearly refers to the iterator as returning a list of changed files. 
The applicants respectfully point out that determining a list of changed files, as Sarkar' s iterator 
does, is a straightforward process and is sufficient for Sarkar' s anti-virus scanning process. 
However, this is totally different from the more difficult problem of determining the changed 
data within a file, as the applicants do. Indeed, Sarkar' s anti-virus scanning process and the 
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applicants' block-level backup data process, as recited in amended claim 6, are not even 
comparable for all the reasons set forth above. 

Claim 6 is thus believed to be patentably distinct from Sarkar under 35 USC 102(e). 

The applicants respectfully traverse the rejection of claims 7-10 under 35 USC 102(b) on 
Uemura for the following reasons. 

The Office Action states on page 8: ". . .as clearly disclosed in the title and the abstract, 
Uemura teaches an incremental backup system, i.e. backup system in which data of the files get 
backed up/archived as the files are growing /modified that is the same as backing up the sparse 
files as claimed in the specification" [emphasis added] The applicants respectfully take issue 
with this statement and points out that an incremental backup of a file is not the same as backing 
up a sparse file. Indeed, sparse files are described in the specification (e.g., in paragraph [0004]) 
and are, moreover, well-known in the art as having portions that do not contain user data, i.e., 
"holes". In fact, the differences between "incremental backup" and "backing up sparse files" is 
not only well-known in the art, but are highlighted in the specification, for example, in paragraph 
[0027] where it is stated that ".. .another embodiment provides a method for retrieving all of the 
non-zero data in a sparse file (as opposed to the incremental changes only)", [emphasis added] 
In particular, as explained in the specification, for example, in paragraphs [0004] through [0006], 
an issue with reading a sparse file for backup is to return an indication of the hole, as opposed to 
a predefined value such as a "0", in order to allow the backup program to write the hole into a 
previously backed up version of the file, thus allowing the file system to reclaim disk space. The 
applicants have advantageously provided a solution to this problem which is in no way addressed 
by Uemura. 

Therefore, the applicants respectfully submit that it is clear that Uemura does not teach or 
suggest dealing with sparse files, whereas the applicants' invention as recited in claims 7-10 is 
directed specifically to backing up sparse files. In particular, Uemura' s incremental backup 
system is totally different from the applicants' method for backing up sparse files which, as 
recited in amended claims 7-10, comprises "writing to a backup file in an write request to a file 
system in which at least one user specified portion of said file is defined to have a specified value 
and in which the size of said at least one portion is specified by said user, said write request 
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providing the capability for application programs to determine changes to said file by reading 
only blocks of said file that contain new data." 

Claims 7-10, particularly as amended, are thus believed to be patentable over Uemura 
under 35 USC 102. 

For all the above reasons, claims 1-3 and 5-13, particularly as amended, are believed to 
be patentable to the applicants. Reconsideration and allowance of these claims are thus 
respectfully requested. 

Should the Examiner have any further concerns regarding this application, he is invited 
to contact Applicants' representative at the below listed number. As requeste^bynhe-Examiner, 
enclosed herewith is a diskette containing-a^opy of the Response to Office? Action. J 

Ml M. Breedlove 
^Attorney for Applicants 
Registration No.: 32,684 

Dated: January^ k 2006. 

HESLIN ROTHENBERG FARLEY & MESITI P.C. 

5 Columbia Circle 

Albany, New York 12203-5160 

Telephone: (518)452-5600 

Facsimile: (518)452-5579 
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